Remotely Gauging Upstream Bufferbloat Delays

“Bufferbloat” is the growth in buffer size that has led Internet delays to occasionally exceed the light propagation delay from the Earth to the Moon. Manufacturers have built in large buffers to prevent losses on Wi-Fi, cable and ADSL links. But the combination of some links’ limited bandwidth with TCP’s tendency to saturate that bandwidth results in excessive queuing delays. In response, new congestion control protocols such as BitTorrent’s uTP/LEDBAT aim at explicitly limiting the delay that they add over the bottleneck link. This work proposes and validate a methodology to monitor the upstream queuing delay experienced by remote hosts, both those using LEDBAT, through LEDBAT’s native one-way delay measurements, and those using TCP (via the Timestamp Option). 1 Problem statement As a recent CACM article points out, “Internet delays now are as common as they are maddening” [3]. Currently, the combination of excessive buffer sizes (aka bufferbloat), with TCP’s congestion control mechanism (which forces a bottleneck buffer to fill and generate a loss before the sender reduces its rate), queuing delays can potentially reach a few seconds [8]. This is confirmed by recent studies such as [5], showing that most home gateways have a fixed buffer size, irrespective of the uplink capacity. With cable and ADSL modem buffers ranging from, on average, 120 KB to a maximum of 365 KB [5], and common uplink rates of 1 Mbps, worst case queuing delays can range from 1 second on average to a maximum of 3 seconds. To counter this problem, BitTorrent developers have proposed IETF LEDBAT [9] as a TCP replacement for data transfer. Like TCP, LEDBAT maintains a congestion window – but whereas mainstream TCP variants use loss-based congestion control (growing with ACKs and shrinking with losses), LEDBAT estimates the queuing delay on the bottleneck link and tunes the window size in an effort to achieve a target level of queuing delay (100ms by default). By explicitly capping the queuing delay, LEDBAT aims at protecting VoIP [2] and other interactive traffic (e.g., Web, Gaming) by congestion self-induced by other traffic of the same user. Although TCP’s loss-based congestion control, coupled with large buffers, can clearly cause significant bufferbloat delays, it is unclear how often this happens in practice, and how badly it hurts user performance. Indeed, active approaches such as Netalyzer [8], likely overestimate bufferbloat delay – by purposely filling the pipe, Netalyzer learns the maximum bufferbloat delay, but not its typical range. To counter this limitation, we design and validate a passive methodology for inferring the queuing delays encountered by remote LEDBAT and TCP hosts. trx,i-1 ttx,i-1 trx,i-1 ttx,i ttx,i-1